The Metrics Server for Kubernetes Dashboard#

If we take a closer look into our Kubernetes Dashboard, especially on the page with listed Pods, we might see that something is missing. To be specific, there are no illustrative curve charts that represent how much CPU and memory are consumed by applications, as givenbelow:

CPU and Memory usage charts in Kubernetes Dashboard
CPU and Memory usage charts in Kubernetes Dashboard

In this lesson, we’ll address this problem and tune our Helm release to show it.

To enable it we need to have the Kubernetes Metrics Server installed in our cluster. This is an application that collects information about resource usage (such as CPU and memory) from the cluster and exposes it using an API. Then an API is consumed by the Dashboard.

Enable the Metrics Server#

There are a couple of ways of deploying the Metrics Server into the cluster. It could be already provided by a public cloud provider or it could be installed with Helm using a separate Helm chart. Luckily for us, we don’t need to use a separate Helm chart. The Metrics Server is already embedded in our Helm chart. We just need to enable it. To learn how to do that, we need to have a look into the values.yaml file and find a part that is responsible for that, as shown below:

A snippet from the official Kubernetes Dashboard values.yaml file

Here, two main properties are responsible for enabling Metrics Servers—metricsScraper and metrics-server. By default, both of them are disabled.

Also, please note how descriptive and informative the comments here are. It’s a good practice to put them into a values.yaml file to help the users of a chart figure out what the purpose of each property is. (This advice will come in handy when we start to create our chart.)

The dashboard.yaml file with the enabled Metrics Server

Apart from enabling both metricsScraper and metrics-server, we need to add two arguments to the server startup command to skip security protection (since we’re developing everything locally).

With that, we’re ready to apply it to our cluster. But there is a problem here.

The helm install command can be used only when we install a Helm release for the first time. If we want to adjust an already existing one we need to use helm upgrade.

Helm upgrade#

It works very similarly to the helm install command. We can check their definitions (using the --help flag) and see for ourselves that they have a lot in common. Later in this lesson, we’ll explain what the differences between these two are.

Now, let’s upgrade our Helm release:

Upgrading the Helm release with new values from the dashboard.yaml file

To verify the number of Pods you can run the kubectl get pods -n monitoring command.

  1. Set up kubectl proxy as follows:
kubectl proxy --address 0.0.0.0 --accept-hosts='.*'
  1. Open a new terminal

  2. Create a ClusterRoleBinding

kubectl -n monitoring create clusterrolebinding dashboard-kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=monitoring:dashboard-kubernetes-dashboard
  1. List the secrets, as shown below:
kubectl get secrets -n monitoring
  1. Get the token, as follows:
kubectl describe secret -n monitoring dashboard-kubernetes-dashboard-token-<INDIVIDUALT-SUFFIX>
  1. Then, open the URL provided at the bottom of code sandbox:
/
dashboard.yaml

First, let’s look at the parameters that were provided into the command:

  • helm upgrade: This is the basic command for upgrading an already existing Helm release.

  • [NAME]: This is the name of the Helm release for which change will be applied; here, it is dashboard.

  • [CHART]: This is the name of the Helm chart for which change will be applied; here it is kubernetes-dashboard/kubernetes-dashboard.

Apart from the mandatory arguments, two other parameters were provided, as follows:

  • -n monitoring: This is the Kubernetes namespace name where the upgraded Helm release is located.

helm upgrade  dashboard kubernetes-dashboard/kubernetes-dashboard -n monitoring --values dashboard.yaml
helm upgrade  dashboard kubernetes-dashboard/kubernetes-dashboard -n monitoring --values dashboard.yaml
Command for upgrading a Helm Release
Command for upgrading a Helm...
Name of a Helm Release
Name of a Helm R...
Name of a Helm Chart
Name of a Helm C...
Kubernetes Namespace name
Kubernetes Names...
Path to a YAML file with overridden values
Path to a YAML f...
Viewer does not support full SVG 1.1
The Helm Upgrade command

We can also find two other arguments which are not mandatory, but they make sure that a release will be installed in the interactive widget. These are as follows:

  • --install: This makes sure that if a release isn’t installed yet, it will be.

  • --create-namespace: This creates a Kubernates namespace if it doesn’t exist.

Validate the Helm release after an update#

Check the Dashboard page#

First, let’s test to see if Metrics are enabled in our Dashboard. To do that, open it in a browser (the hint above the interactive playground will help refresh your memory).

If we go now to the Pods page or the specific Pod view, we can see illustrative charts, as shown below.

CPU and Memory usage for a specific Pod
CPU and Memory usage for a specific Pod

Review the history of the releases #

Now, let’s examine our release with Helm CLI. First, let’s see what has changed in the helm list:

Listing releases in monitoring namespace

The output will be as follows:

NAME       REVISION  UPDATED    STATUS    APP VERSION
dashboard  2         2021-12-01 deployed  2.4.0

Our dashboard Helm release has been bumped up to revision 2.

If we want to check all the revisions we can use a very handy command, helm history:

Listing revisions for a dashboard Helm release

The output will be as follows:

REVISION  UPDATED     STATUS     CHART           
1         Dec 1 2021  superseded  kubernetes-dashboard-5.0.4  Install complete
2         Dec 1 2021  deployed    kubernetes-dashboard-5.0.4  Upgrade complete

From the above output, we can see that the 1 revision is now outdated (superseded) and the latest version, 2, has been deployed.

Check the overridden values#

Moreover, we can check what values have been applied to this specific release using the already mentioned helm get command:

Printing values provided during the installation

The output will be as follows:

USER-SUPPLIED VALUES:
metrics-server:
  args:
  - --kubelet-preferred-address-types=InternalIP
  - --kubelet-insecure-tls
  enabled: true
metricsScraper:
  enabled: true

This time, however, we don’t use helm get all but the helm get values command which prints only those values that have been provided by us. We can use this command to debug our Helm release, which can be very useful in complex systems.

Setting Values during Installation

Install Helm Release with Multiple Values Files